【レポート】内製開発とパートナー共創体制で実現するAWSファーストへのLift&Shift #AWSSummit

AWS Summit Osaka 2019

#AWS

豊崎隆

2019.06.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ご機嫌いかがでしょうか、豊崎です。

2019年06月27日に大阪のグランフロントで開催されていたAWS Summit Osaka 2019をライブストリーミングを拝聴しました。

本記事で取りあげるセッションは、「内製開発とパートナー共創体制で実現するAWSファーストへのLift&Shift」です。

スピーカー情報

スピーカー：アマゾンウェブサービスジャパン株式会社アドバイザリーコンサルタント川嶋俊貴様

レポート

AWSとの出会い BEFORE / AFTER

BEFORE

NTTスマイルエナジーに置ける開発部門の役割
- 組織の役割
  - ビジネス・システムの「企画」に特化
    - 開発は強みのある協業パートナーに業務委託
    - 基本的にはスクラッチ開発
  - 開発体制
    - インフラ基盤は某社クラウドを利用
    - インフラ基盤は構築、運用は協業パートナーに業務委託
    - アプリ開発は協業パートナー（複数）に業務委託
- 課題
  - 市場変化にサービスレベルが追従できない
    - 実際の開発はほぼパートナー頼み
    - 品質・コスト・納期のコントロールが難しい
    - 「とりあえず新しいことやってみる」がほぼ無理
  - ツギハギ回収の積み重ねでシステムトラブル＆運用負荷増大
    - 複雑なシステム構成
    - 属人運用＆ノウハウの非継承
    - トラブル続きで運用担当者の負荷増
- AWS Summit Tokyo 2016
  - 使えそう＆挑戦してみたい公開事例が多数あった

AFTER

変化の方向性を決める
- 組織の役割
  - AWSを活用した内製開発をやれる組織になる
  - パートナーと技術的に対等な関係性を築けるレベルになる
  - 自前主義から脱却
- 開発体制
  - AWS中心の自社運用体制
  - AWS採用前提の開発体制
  - SREチーム発足

NTTスマイルエナジー流内製開発＆パートナー連携術

理想と現実のギャップ
- 理想
  - AWS使って開発
  - パートナー企業と対等に議論を交わして開発
  - スクラッチ開発は不要
- 現実
  - AWSよくわからない
  - 今更対等になれるのか？
  - 社内の要望を完璧に実現するにはスクラッチ以外手段なし
- APNパートナーへ相談
  - パートナー主催のセミナーへ参加
  - 有志の勉強会に参加
  - JAWSーUGに参加
  - AWS主催のイベント参加も有益
パートナー企業との協業方針
- 一方的に要望を伝える関係にしない
  - 信頼関係の構築
- パートナーの良いところから学ぶ
  - 良いやり方、ツールなどどんどん吸収する
- パートナー企業のメリットに繋がる仕事にする
  - 初事例や実績につながるもの
  - 他者への紹介につながる
組織変革の３ステップ
- ホップ
  - 簡単なものから社内AWS事例の積み上げ
  - 社内の布教活動
- ステップ
  - 難易度が少し高いものにチャレンジ
  - 実績報告による経験層の理解浸透
- ジャンプ
  - 内製開発の動きを加速（チーム設立）
  - 難易度：高い（Shift施策）にチャレンジ
ホップ
- 状況
  - 当初二人で活動
  - 内製開発経験は皆無
- 施策
  - AWS関連ニュースの共有
  - 小規模のPoCの実施
  - PoC施策の実績共有
- 変化
  - 徐々にAWSに興味がある人が増えてくる
ステップ
- 状況
  - AWS利用の意欲増：しかしわからないことが多い
  - 経営陣のAWS理解は「従量課金で高い」「使い勝手悪」
- 施策
  - AWS適用施策の検討とアサイン
  - 開発者への積極的なサポート
  - 経営陣への定期的な実績報告
- 変化
  - AWSだといろいろできそう
  - 自分で色々できるの楽しい！やりがい・楽しさを感じる
  - 経営層の意識変化
ジャンプ
- 状況
  - 社内での活用事例が増える
  - EC2/CLB/S3/RDSなどが使えるように
  - 従来システムの置き換え程度の開発経験しかない
- 施策
  - SREチームの設立
    - とにかく高速に改善を回してサービスの質向上
    - 属人業務の排除
    - 自社対応を可能とし品質・スピード低下の改善
  - ３つの挑戦的施策を企画・実行
    - MS SQL Server 2008R2→AuroraへのDBマイグレーション
    - CloudEndure（当時有料）によるVPS→EC2移行
    - サーバレスによる新規サービス開発
現在の取り組み
- CI/CD環境の整備、ルール策定
- 開発委託におけるアーキテクチャ検討への関与
- DevSecOpsの推進

大規模なLift&Shiftプロジェクトから得た学び

AWS移行を決めた背景
- 運用改善
  - 新機能リリースのスピード向上、コスト削減
  - ロールバックなどにおけるストレスがないリリース実現
  - 従来型の保守運用業務からの解放
- 性能改善
  - データ計算処理時間性能
  - Webサイトの表示時間性能
  - DB処理性能
- 一番実現したい事
  - もっと新サービス開発に注力できる開発体制を築くこと
AWS移行によって実現される事
- サーバ管理不要
- リリースのストレスから解放
- リソース調達不要
プロジェクトにおける取り組みと学び
- 複数チーム間での連携
  - Slack
  - backlog
  - Google Hangout/meet
- 信頼関係がもっとも大事
- バッチ処理の課題
  - AWS Lambdaで解決
    - 処理性能の向上
    - デプロイにおける制約からの解放
    - 内製開発チームのスキルとモチベーション向上
- 新技術への切り替えコストが高くてもメリットが大きい場合がある
  - 初めからShiftを恐れないことが大事
まとめ
- 重要なこと
  - 同じ目的に向けたチーム作り
  - 新しいことに挑戦する勇気
- AWSを活用することで
- 注力するべき問題のみにフォーカスできるようになる
  - 新しいことに挑戦する意欲を与えてくれる

変革を遂げた開発チーム

変革を遂げた開発チーム
- AWSを活用した内製開発が当然に
- パートナー提案だけでなく、社内からも提案・議論しより良いものを作成する姿勢
- 他社の先進事例を積極的に取り組み合理的な開発姿勢
- 新しいことへのチャレンジを恐れない姿勢
まとめ
- 新しいことにチャレンジしやすいAWSだからこそ組織改革のきっかけに活用すべき
- AWSを十二分に活用するなら少しでもいいので自社開発運用を目指すべき
- リソースの限られる中小企業はクラウドは選択と集中で取り組むべき
- AWSは関連情報が多いのでパートナー企業やサポートをフル活用するべき